Release 10.1A: OpenEdge Development:
Java Open Clients

Providing meta data for INPUT TABLE-HANDLE parameters

For TABLE parameters, the proxy calls the next() and getObject() methods to get the data that needs to be passed to the AppServer methods. For a TABLE-HANDLE parameter, the proxy must first call the getMetaData() method to determine the format of the data.

There are several alternatives for how getMetaData() can supply the appropriate ResultSetMetaData object:

Use a standard JDBC ResultSet.

If the input ResultSet is a standard JDBC ResultSet obtained from a query, the client application does not need to do anything. The ResultSet instance already implements the getMetaData() method and returns a standard ResultSetMetaData object.

The proxy automatically maps SQL data types to Progress schema data types, as shown in Table C–5.

Note: Because a standard ResultSet supports a standard ResultSetMetaData object and not the Progress extension (ProResultSetMetaData), there can be no array fields.

Table C–5: Mapping between SQL and Progress 4GL schema data types for standard JDBC ResultSet

SQL type	Progress 4GL type
BIT	LOGICAL
BLOB	BLOB
CLOB	CLOB
DATE	DATE
DECIMAL	DECIMAL
INTEGER	INTEGER
LONGVARCHAR	CHARACTER
TIMESTAMP	DATETIME
VARBINARY	RAW

If the ResultSet contains any other type, an exception is thrown.

Extend Progress’ InputResultSet.
If the ResultSet contains a column type other than the types shown in Table C–5 and the column can be converted to a compliant type, implement your own ResultSet class instead of passing the java.sql.ResultSet directly as the parameter. For example, you can extend com.progress.open4gl.InputResultSet with your own class.

When getObject() is called on your class, it retrieves data from the corresponding standard object and converts the data before returning it to the proxy. When the getMetaData() method is called, the implementation of your extended class must supply the appropriate meta data. To do this, the application must create and populate a ProResultSetMetaDataImpl object, as described in the "ProResultSetMetaDataImpl class" section”.

If the application requires the resulting server-side temp-table to have an array field, this is another reason for you to extend the InputResultSet class. This time, the implementation of both next() and getObject() call the standard instance’s corresponding methods to do the work. When the getMetaData() method is called, however, the extending class must supply the required meta data, with the flattened schema view converted to the corresponding array field view. Again, to do this, the application must create and populate a ProResultSetMetaDataImpl object, as described in the "ProResultSetMetaDataImpl class" section”.
Use the ResultSetMetaData from a previously obtained output ResultSet under the following condition:
If the input ResultSet is a ResultSet that was first obtained from the AppServer through an OUTPUT parameter, meta data can be obtained from that output set by calling getMetaData() on it. You can think of this as an OUTPUT-INPUT TABLE-HANDLE, parameter even though it is output from one method call and input through another. The ResultSetMetaData object obtained from the output ResultSet can then be provided when getMetaData() is called for the input ResultSet.

ProResultSetMetaDataImpl class

If the meta data for the input ResultSet must be supplied by code implemented in the client application, the getMetaData() method must be implemented to return an instance of ResultSetMetaData. The recommended way to do this is to use the com.progress.open4gl.ProResultSetMetaDataImpl class provided in the Open Client Toolkit. This is an implementation of the ProResultSetMetaData interface, the same interface that is used by the client when getting output data.

The only two methods of ProResultSetMetaDataImpl the application must call are the constructor and the SetFieldMetaData() method, as follows:

Syntax

ProResultSetMetaDataImpl(int numFields)

Syntax

SetFieldMetaData(int fieldNumber, String Name, int extent, int type)

The SetFieldMetaData() method requires the following:

fieldNumber must be between 1 and the number of fields.
Name cannot be null.
The value of Name must be unique within the table.
extent must be zero or greater (for BLOB and CLOB fields, it must be zero or one).
type must be one of the class constant values defined in com.progress.open4gl.Parameter. For more information, see the information on specifying data type meta data for temp-tables in Chapter 4, " Passing Parameters."
Note: The Open Client Toolkit class documentation in OpenEdge-install-directory/java/doc/ also describes these methods used by the client application for the ProResultSetMetaDataImpl class.

To pass a self-implemented ResultSet for a TABLE–HANDLE parameter, the application must:

Create a new class that extends com.progress.open4gl.InputResultSet, to provide access to the data to be passed to the server. This object’s implementation includes code for next() and getObject() (as for a static temp-table) and for getMetaData(), which should return the com.progress.open4gl.ProResultSetMetaDataImpl instance when called.
Create an instance of the class you created in Step 1.
Create an instance of com.progress.open4gl.ProResultSetMetaDataImpl.
Call ProResultSetMetaDataImpl.setFieldMetaData() for each field of the table.
Make the ProResultSetMetaDataImpl instance available to the InputResultSet object. You can do this in any way you like, for example, by adding a setMetaData() method to your InputResultSet implementation.
Make the proxy method call passing the com.progress.open4gl.InputResultSet instance as the parameter.
Note: Step 3 and Step 4 can be implemented in getMetaData() which eliminates the need for Step 5.